1. Field of the Invention
The present invention relates to systems for irrigation management and control. More particularly, the present invention relates to remotely updating microprocessor code in irrigation controllers, optionally where the controllers are networked.
2. Description of the Related Art
Today's irrigation management and control system may incorporate programmable functions into irrigation controllers. For example, stand-alone controllers that control multiple irrigation valves are used for smaller irrigation sites. The stand-alone controller offers a user interface, so that a user can set up automatic watering programs, perform manual watering, as well as perform some additional functions for irrigation control, and perhaps program various of these features.
A single controller is insufficient in larger installations because the distance between the controller and valve stations is too great. Multiple stand-alone systems can be used, but are awkward to control. An alternative is a central satellite control system, consisting generally of various sense and/or control devices (controllers) linked together in a satellite configuration via a communication bus and managed by a personal computer.
The satellite controller is similar to a stand-alone controller, which offers both valve control and various sensor interfaces. More sophisticated satellite controllers also have a user interface for local programming.
A controller may include a microprocessor, a general function of which generally is to accumulate information from input sources, and in turn use this data to control outputs. For example, a keypad and display may be used to input a desired watering schedule. The microprocessor will receive this data and transfer it to memory. The microprocessor may use a timer or other clock source to keep track of time, and when the start time of the user programmed watering schedule is recognized, the microprocessor will retrieve it from memory. It will then assert the state(s) of the valve output drivers as required.
Some aspects of conventional systems are illustrated by way of example in FIG. 1, shown in U.S. Pat. No. 6,314,340, Mecham et al. (expressly incorporated herein by reference). Mecham illustrates one example of a conventional irrigation controller 110. The controller 110 includes microprocessor (CPU) 112, a programmable read only memory (ROM/PROM) 114 and a random access memory (RAM) 116. The ROM/PROM 114 provides a non-volatile storage location for the programming code of the controller along with certain important (permanent) data necessary for execution of the code. The RAM 116 provides a volatile storage location for certain variable or temporary data generated during execution of the programming code. The microprocessor 112 communicates via an address bus 118 and a data bus 120. Data entry is via a user interface 126 or using a serial data download. A display 128 supports visual data presentation. A serial communications port 130 is provided between the controller 110 and external devices. Through this serial port 130, the programming code (and data) stored in the ROM/PROM 114 may be updated and data may be extracted from or downloaded to the RAM 116. A time of day clock 132 is provided. The microprocessor 112 outputs irrigation control signals to control the actuation of irrigation control valves 140 that control sprinklers 142. Input is provided via I/O bus 124 from temperature sensor 122, and other sensors 146, e.g., a moisture sensor 146 (1) or a rainfall gauge 146 (2).
Normally, operating code on a microprocessor is re-programmed by removing the microprocessor chip, reprogramming the chip, and re-installing the chip. While the above-mentioned solutions and others provide for individually customizable controllers, they fail to address the problem of quickly providing changes to microprocessor code itself in numerous controllers in the field. In the field, the result has been the need to individually remove and install, for example, microprocessor chips with upgraded firmware one-by-one. Needless to say, this is time-consuming and error prone.
The problem is exacerbated further where the controllers are distant from one another, such as at a large golf course installation. In addition, because of the difficulty of the problem, small error corrections in the microprocessor code tend to be put off and allowed to accumulate.
In an ideal world, however, corrections would be promptly installed. Therefore, there is a need for an ability to change out or update the operating system while it is still operating, in the field.
The result is a need for a solution in the field to the problem of repetitious and error-prone firmware installations. The above prior art references and other conventional systems, however, fail to meet the needs of easily updating firmware in several controllers. Moreover, none of these conventional systems provide for confirming that the desired firmware has been installed system-wide, for example. Users are still looking for a solution to remotely update microprocessor code, in connection with controllers.